/run-e2e dynatrace
Update: You can check the progress here

Please, rebase your branch @cyrilico , the e2e issue was related with some breaking changes in otel-collector which are already fixed in main branch (your tests hasn't been executed yet indeed)

/run-e2e dynatrace
Update: You can check the progress here

/run-e2e dynatrace
Update: You can check the progress here

new changes, please rerun

/run-e2e dynatrace
Update: You can check the progress here

/run-e2e dynatrace
Update: You can check the progress here

Hello,
I've been testing this locally and I found some things:

• The dynatrace operator fails because the token doesn't have enough permissions for it
• The job generators aren't generating the load because the values are overridden
  

For the dynatrace operator issue, I've created a new secret 'DYNATRACE_OPERATOR_TOKEN', please use it for the operator and the other one for metrics (including for reading them by KEDA)

After making these changes, I see that dynatrace operator has created more pods:

But the metric isn't still available:

I think that the issue can be in something related with the e2e test configuration because I can see that KEDA is querying the value and getting an empty response with status 200 (so from KEDA side seems that works)

Appreciate the help @JorTurFer 🙏 What metrics are available in that page? The one I used is supposed to be a built-in, i.e., supported OOTB, so I'm curious as to what exactly is available in that dynatrace environment

Any news @JorTurFer ? 🙏

Any news @JorTurFer ? 🙏

I have to apologize for not answering before, I've been involved on a huge working peak :(
I'll try to review this ASAP. I guess that the issue with the metrics was that they needed more time to be consolidated, maybe we can use an approach like the Azure Monitor one, just querying about any available metric as default and updating the ScaledObject to trigger the scaling. e.g: Imagine that you can return an arbitrary number and you use it for scaling, at the end of the day, we don't need to check that the vendor calculates correctly the metric but just the connectivity

Thanks, I have noticed in the corporate instance I have access to that Dynatrace does take a minute (sometimes literally) to ingest a data point, so I believe that might be an interesting approach. I'll take a look at the Azure Monitor scaler and try to get some inspiration

For instance, influx does it too: https://github.com/kedacore/keda/blob/main/tests/scalers/influxdb/influxdb_test.go#L106-L117

It sets the expected value within the query and just updating the ScaledObject you change the received value.

And this is the Azure log analytics one (I said azure monitor worngly): https://github.com/kedacore/keda/blob/main/tests/scalers/azure/azure_log_analytics/azure_log_analytics_test.go#L113-L123

@JorTurFer couldn't find an exact map to replicate that mechanism in Dynatrace (other than potentially mocking the API calls, which would invalidate the connection testing part), so I've tried a configurable default value filter available in their query language spec; can we have another e2e test run?

/run-e2e dynatrace
Update: You can check the progress here

Hello,
I'm so sorry due to the long silent from my side and I'd like to apologize, my life's been complicated during last months. During this week and next week I'll be focus on this PR (and others) aiming to include them within next week release.
Thanks for your contribution :)

/run-e2e dynatrace
Update: You can check the progress here

@cyrilico , I've updated the e2e test to use custom metrics. We have the full control over them and they don't need the agent or any other service, just POST to ingest and KEDA will read them 😄
It's the same approach that we use for Azure Application Insights

/run-e2e dynatrace
Update: You can check the progress here

done @zroubalik 👌

/run-e2e dynatrace
Update: You can check the progress here

Thank you, makes life easier now. Don't have to deploy Prometheus server additionally on each cluster.